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HETHOD AND APPARAOTaS FOR MAIQAGXISG A 

coiaj3C^xaix of poriclbts xn a portai. sosrver 

Field o£ the Xnvention 

This invention relates to the Internet, more particularly to methods 
and apparatus for producing and using portals and portlets in web 
applications to provide enhanced capabilities • for web sites , 

Sackaro "^"^ the invenfcAon 

The World Wide Web brought a paradigm shift to communications over 
the Internet, conveying graphical information to users. With the advent of 
the Web there was and still is demand for increasing communicability and 
broad connectivity. 

^ The Portal (previously known as a web portal) has brought a major 
paradigm shift in internet space. A wefa site that offers an array of 
resources or services such as email, ^forums, search engines ^ databases or 
other information may be considered to be a portal. The first web portals 
may have been online services. For the first time, users surfing the ^ 
internet were able to see web pages that were assembled with and offered* 
information coming from various sites in the world wide web, yet the 
aggregation's constitution was transparent to- the user. A user making use 
of a typical web browser sees a cohesive web page displayed. The 
origination of different parts of the page from vsorious internet sites not 
associated with the web site being viewed is not readily apparent. These 
parts aure termed Portlets. 

Portlets are the visible active components end users see within 
their portal pages. Similar to a window in a PC desktpp, each portlet 
^owns* a portion of the browser or Personal Digital Appliance screen where 
it displays results. 

From a user's view, a portlet is a content channel or application to 
which a user subscribes, adds to their personal portal page, and 
configures to show personalized content. 

From content providers' view, a portlet is a means to make available 
their content. 



wo 2004/031987 



PCT/GB2003/004248 



2 

Prom a portal administrator's view, a portlet is a content container 
that can be registered .witli the portal, so that users may subscribe to it. 

From a portal's point of view, a portlet is a component rendered 
into one of its pages.. 

From a technical point of view, a portlet is a piece of code or a 
small application that runs on a portal server and provides content that 
is to be embedded into portal pages. In the simplest terms, a portlet may 
be a Java*" servlet that operates inside a portal. 

Each part (portlet) of a given page (typically sourced from 
different places in the world wide web) can collaborate with another part * 
(portlet) of the same page to achieve higher function for a user surfing 
or accessing the page. Thus, a portal becomes the single point of access 
for multiple users, via multiple channels, to multiple sources of 
information. 

Portals can be applied in various business models, namely: business 
to consumer, business to business, or bu&iness to enterprise, l*ie key to 
quick adoption of the portal peuradlgm ties strongly to its ability to 
integrate existing web application data into the portal framework in a 
seamless fashion. 

However, various technical hurdles still exist for such seamless web 
application integration into portal. 

There are limitations in the prior art concerning how the following 
portal artifacts work together with existing web applications. The 
in«>leraentation of integration of web applications into portal architecture 
is not well defined. These entities include: 

Original http request to a portal; 

A portlet session within a portal; 

A http request from the portal to the pertinent web application. 

When different users access a portal page, the original http request 
for each user is directed towards tbe portal server (a) . The original http 
session for each user is also entirely 'owned* by the portal server. Each 
of the portlets has its own independent session called a portlet session. 
Vflien a portlet needs to render information that comes from a given web 
application, (b) , there are typically the following technical hurdles: 
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i. There is no existing mechanism for a portlet to generate http 
requests and responses to and from the backend web 
application. 

j. There is no existing mechanism to manage multiple requests and 
xesponses to a calling portlet (and the portlet session) 
mapping correctly with multiple recjuests and responses to a 
backend web application (and the web application's session) . 
Each (both portlet and web application) maintains its user 
session accordingly. 

This gets complicated when multiple portlets call the same web 
application, with the web application treating these multiple portlets 
requests within the same web application session, 

k. There is no existing mechanism to relay session information' 
between the multiple portlet sessions and the web 
application's session. 

When a well def ined set of portlets within the same portlet 
application interact with the one web application at the backend, all the 
participating portlets must be able to retrieve and forward the correct 
session infozmation to the web application at the backend such that the 
information rendered from the web application is consistent with the 
setting of that of the portal of the portlets. Examples of such setting . 
includes locale information, \iser agent of that particular access etc. For 
exanqple, the responses sent from the web application muist be using the 
same locale with the portlet in the portal server who displays it. 

There is no existing mechanism for single sign on such that the 
portal user's credentials will not be challenged by the backend web 
application. This is a critical requirement. The absence of it will result 
in the user's credentials being challenged when the user moves from one 
part of a web page to a different part of the same web page; as the 
portlets have different originations and identification requirements. 

There is no existing mechanism for synchronization of xmiltiple 
requests or responses between portlets of a given portlet application and 
the pertinent web application backend. 

The prior art has limitations concerning how multiple portlets 
within the same portlet application can collaborate with one another • 
(sharing the same context) as well as with the various integrated web 
applications dynamically is not defined. 



wo 2004/031987 PCT/GB2003/004248 



One Usage Scenario involving multiple portlets collaborating by 
sharing the same * context' dynamically will seanre to conceptually 
illustrate the limitation: 

5 With three portlets being displayed on the same portal web page: 

- one portlet shows the account summary by displaying a list of 
accounts 

- the second portlet shows a given account's list of outstanding 

invoices 

10 - the third portlet shows a given account's order history summary 

The . second and the third portlets are contextually bo\md to the 
first portlet dynamically, reflecting outstanding invoices 12^ portlet) 
and order history (3^** portlet) and are synchronized with an account 
15 selected from the accooant list of the first portlet, 

Limitations of the prior art: 

i. No mechanism exists to define a sub-grouping of portlets within a 
portlet application that would work collaboratively. 

20 

3. No mechanism exists to define a context (that can be ^v^amically 
changed) shared among this sub-group of portlets within a given 
portlet application: example of context here is the selected account 
in portlet 1, such account selection can be changed dynamically* 

25 

k. No mechanism exists to detect the change in context ^ynamicsilly: 
example of the change of selection from one account to another 
account from the account list in portlet 1 of the above example, 

30 1. No mechanism exists to register a predefined action (or responses) 

for each participating portlets within the sub-group of portlets 
that share the same context: example of displaying the list of 
outstanding invoices (action in portlet 2) when the context is 
changed (from one accoimt selection to another in portlet 1). 



35 



m. No mechanism exists to relay that dynamic context to the relevant 
integrated web applications 



40 



There is no mechanism existing in the prior art to define a refresh 
sequence for a group of portlets within a portlet application 
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i. There is no provision today for a portal designer to specify the 
refresh order of a given set of portlets being displayed. 

In our scenario above, the portal designer would want to have the 
first portlet (accoiant list) refreshed first, the second portlet refreshed 
second etc. so that the 2"* and the 3"* portlets automatically have. Defined 
actions (when the portlet Is deployed) talcing place in a correct sequence. 

There is a lack of . a well defined mechanism in portal architecture 
to support the aggregation of portlets based on business rule and user 
profiling information including the users' role. 

i. There is no existing mechanism to define aggregation of portal 
resources per user based on business rules. 

Hxainple: all teenage portal users see one group of portlets, all 
senior portal users see another group of portlets. 

j . There is no existing mechanism for such rule based and user based' 
aggregation of portlets that is performed dynamically at runtime. 

There is no sharing of portal level business rules and user profile 
information with pertinent integrated back end web applications. 

There is no sharing of business rules or user segmentation 
information with an integrated web application such that these rules and 
user segmentation can be consistent across a portal and its integrated 
backend web application. For example, if there is a rule defining the age 
range of a teenager, such a rule should be visible and applicable to the 
integrated web application for consistency. 

Ternulnoloqv 
l^piTtlefcs 

Portlets are the visible active components that the end users see 
within their portal web pages. Similar to a window in a PC desktop, each 
portlet *owns" a portion of the browser or PDA (Personal Digital 
Appliance) screen where it displays portlet specific infonaation. 
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Portlet: anplication 

Port lets can slLso be grouped together in a portlet application. 
Portlet applications are distributed and deployed using Web archive files 
5 (WAR) . There are portlet specific extensions to the standard Web 

application deployment descriptor, 

Portlet: Btessaqea 

Portlet messages aire used for the communication between two portleta 
using portlet actions cuid portlet messages. The sending portlet creates a 
portlet action, encodes the action into a DRii. When the URL is addressed, 
e.g. by a user trying to accon^lish an task, the action listener is called 
and sends a portlet message to send the necessary data. 

Portlet B&aB±cin, 

A Portlet session is created for each portlet Instance for each user 
logging on to maintain session information for each user per portlet 
instance. 

Summary of tha lnve»H:i.Qn 

The various embodiments of the invention herein address one or more 
25 shortcomings of the prior art. 

When users access a portal page, the original http request for each 
user is directed towards the portal searver. Each of the portlets has its 
own independent session called a portlet session. An embodiment of the 
invention provides a system for synchronization of imiltiple requests or 
responses between portlets of a given portlet application and the 
pertinent web application backend and there was no existing mechanism for 
portlets of a given portlet application to generate http requests and 
responses to and from the backend web application in such a manner that 
the back end http session is maintained cohesively. 

One aspect of the invention provides a set of methods to enable a 
collection of portlets within the same portlet application to initiate 
portlets requests to access said web application maintaining cohesive 
40 session to the backend application; to manage a portlet application 

session object for said portlets; to provide a common data store for the 
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portlets within the same portlet application including saving parameters 
from user regcu-ests. 

Another embodi men t of the invention provides a portlet application 
cQiraiiunication client in said portlet application for communicating between 
portlet application session object and said web application to convey user 
requests, embodiment also may also provide a common key, granting the 

key to each associated portlet for controlling access to the portlet 
application object. This common key is also used for matching up http 
sessions owned by the portal server and the http sessions owned by the 
backend web application. The communication client may have a request 
buffer for storing and serializing requests from the associated portlets 
to enable the communication client to generate seriaJized to the web 
application. 

With an ^nbodiment of this invention « it is now possible to have a 
coamion backend web application integration model, enabling native portlet 
integration of web application without la\inching separate browsers with a " 
single sign on for a user. Xt also provides mechanism for session 
management between the portlets and the web application backend. 

One embodiment of the invention provides apparatus for displaying to 
a user a web portal for a web application, the web portal displaying a 
plurality of associated .portlets, shearing information with each other, 
accessible by the user; including: a portal server for operating a web 
portal to provide access to the web application; a portlet application for 
operating on the portal server, for managing a collection of associated 
portlets? the portlet application includes: means to initiate portlets on 
requests of a loser to access the web application; means to manage a 
portlet application session object for the portlets; and, a portlet 
application session object data store controlled by the portlet 
application session object for saving parameters from user requests for 
associating the portlets with the with the portlet application session 
object. 

a*he apparatus of the invention may include a portlet application 
communication client in the portlet application for communicating between 
the portlet application session object and the web application to convey 
user requests received from the associated portlets to the web 
application. The portlet application may assign a common key to each 
portlet associated with a portlet application session object. 
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Another embodiment of the invention provides an apparatus for 
displaying a web portal for a web application to a plurality of users, 
the web portal displaying a pl\irality of portlets, sharing information, 
accessible by the users; including: a portal server for operating a web 
portal to provide access to the web application; a portlet application for 
operating on the portal server for each of the plurality of users, for 
inanaging a collection of associated portlets for each of the plurality of 
users; each the portlet application includes: means to initiate portlets 
on reqcuests of one of the plurality of users to access the web 
application; means to manage a portlet application session object for the 
portlets; and, a portlet application session object data store controlled 
by the portlet application session object for saving paurameters from user 
requests for associating the portlets with the with the portlet 
application session object. 

Another embodiment of the invention provides apparatus for. 
displaying to a user a web portal for a plurality of web applications, the 
web portal displaying a plurality of associated portlets, sharing 
information with each other, accessible by the u^er; including: a portal 
server for operating . a web portal to provide access to the web 
application; a pliirality of portlet applications relating respectively to 
the plurality of web applications for operating on the portal server, each 
portlet application being adapted to managing a collection of associated 
portlets; each the portlet application includes: means to initiate 
portlets on requests of a user to access one of the plxirality of web 
application; means to manage a portlet application session object for the 
portlets; and, a portlet application session object data store controlled 
by the portlet application session object for saving parameters from user 
requests for associating the portlets of the portlet application with the 
with the portlet application session object of the portlet application 
session. 

Another aspect of the apparatus of the invention includes a user 
session information table adapted to connect to multiple web applications 
with the portlet application session object. 

Still another embodiment of the invention provides apparatus for 
displaying to a user a web portal for a web application, the web portal 
displaying a plurality of associated portlets, sharing information with 
each other, accessible by the user; including: a portal server for 
operating a web portal to provide access to the web application; a portlet 
application for operating on the portal server, for managing a collection 
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of associated portlets; the portlet application including: means to 
initiate a first portlet on request of a user to access tlie web 
eypplication? means to create a portlet application session object for the 
uaer for the first portlet; means to save parameters from the request; 
means to generate additional portlets associated with the first portlet 
on further requests of the user to access the web application; a portlet 
application session object data store controlled by the portlet 
application session object for using the saved parameters for associating 
the additional portlets with the with the portlet application session 
object; and, means to create a portlet application communication client 
(httpClient) for communicating with the portlet application session object 
and the web application to convey user requests received from the first 
and additional portlets to the web application. 

The apparatus may include a portlet application commcunication client 
in the portlet application for communiGating between the portlet 
application session object and the web application to convey user requests 
received from tbe associated portlets to the web application. 

The portlet application preferably assigns a common key to each 
portlet. associated with a portlet application session, object. 

A user session information table adapted to connect to multiple web 
applications with the portlet application session object may 
advantageously be provided. 

Another aaabodiment of the invention provides apparatus for 
displaying to a user a web portal for a web application, the web portal 
displaying a plxirality of associated portlets, sharing information with 
each other, accessible by the user; including: a portal server operating a 
web portal to provide access to the web application? a portlet application 
operating on the portal server, for managing a collection of associated 
portlets; the portlet application including: means to initiate portlets on 
requests o£ a user to access the web application; means to manage a 
portlet application session object for the portlets? and, a portlet 
application session object data store controlled by the portlet 
application session object for saving parameters from user requests for 
associating the portlets with the with the portlet application session 
object. 

Another aspect of the invention provides a method of sharing 
information between a plurality of associated portlets - in a web portal 
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including: granting access for each of the pliirality of associated 
port lets to a portlet data store; permitting each of the plurality of 
associated portlets to write data to the portlet data stbte and to read 
stored data from the portlet data store. 

Olie method above may advantageously provide a system wherein the 
associated portlets axe meuiaged by a portlet application adapted to 
operate on a data processing system; wherein the portlet data store 
coit^rises portlet application storage managed by a portlet application 
session object which controls reading and writing of data by the 
associated portlets in the data store permitting exchange of data among 
the associated portlets of the portlet application • 

Another aspect of the invention provides apparatus for sharing 
information between multiple associated portlets in a web portal 
including:, a portlet application for managing the multiple associated 
portlets; a portlet application data store; means for granting read/write 
access to the data store by the multiple associate portlets to enable the 
portlets to exchange data among each other. 

yet another aspect of the invention provides a portlet (application) 
server capable of operating on a portal server for hosting multiple 
associated portlets in a web portal including: means for managing the 
multiple associated portlets; means for managing a portlet application 
session object; a portlet application data store managed by the portlet 
application session object for granting read/write access to the data 
store to the multiple associate portlets to enable the associated portlets 
to exchange data among each other. 

Another aspect of the invention provides a portlet (application) 
server capable of operating on a portal server for hosting multiple 
associated portlets in a web portal including: means for managing the 
multiple associated portlets; means for creating eind' managing a portlet 
application session object; a portlet application data store created and 
managed by the portlet application session object for granting read/write 
access to the data store to the multiple associate portlets to enable the 
associated portlets to exchange data among each other. 

Advantageously, the portlet application assigns a common key to each 
portlet associated with a portlet application session object. 
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toother aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
portlets in a web portal accessible by a user, including: portlet 
application means for managing the multiple associated portlets; portlet 
application means for managing a portlet application session object for 
the user; portlet application means for granting the key to each 
associated portlet for controlling access to the portlet application 
ob j ect . 

Still another aspect of the invention provides a portlet application 
capable of operating on a poriial server for hosting multiple associated 
portlets in a web portal accessible loiy a user, including: portlet 
application means for managing the multiple associated portlets; portlet 
application means for creating and managing a portlet application session 
object for the user; portlet application means for creating and managing a 
key for the user for the portlet application session object; portlet 
application means for granting the key to each associated portlet for 
controlling access to the portlet application object. 

Advantageously one portlet application is assigaed to each user and 
one key is assigned respectively for each user to respective portlet 
application objects for each portlet application. 

Another aspect of the invention provides apparatus for displaying to 
a user a web portal for a web application including: a portal server for 
operating a web portal to provide access to the web application by a user; 
a portlet application, for managing a collection of associated portlets, 
for operating on the portal server; a portlet application session object 
for the user for the associated portlets; a portlet application session 
object data store controlled by the portlet application session object; a 
portlet application communication client linked to the portlet application 
data store for communicating between the associated portlets and the web 
application to convey user requests received from the associated portlets 
to the web application; the communication client having a request buffer 
for storing and synchronizing requests from the associated portlets to 
enable the communication client to generate synchronized to the web 
application . 

Preferably the portlet application communication client is adapted 
to send information including requests over a network to a web application 
and receive information including responses to the requests from the web. 
application. 
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Another aspect of the invention provides apparatus for displaying to 
a user a web portal for a web application including: a portal server for 
operating a web portal to provide access to the web application by a user; 
a portlet application, for managing a collection of associated portlets, 
for operating on the portal server; a portlet application session object 
for the user for the associated portlets; a portlet application session 
object data store controlled by the portlet application session object; a 
portlet application coinmunication client linked to the portlet application 
data store for comrmmicating between the associated portlets and the web 
application to convey user requests received from the associated portlets 
to the web application; the communication client having a request buffer 
for storing and serializing requests from the associated portlets to 
enable the comraunication client to generate ser£ali25ed to the web 
application. 

Preferably, the portlet application communication client is adapted 
to send information including requests over a network to a web application 
or web application server and receive information including responses to 
the requests from the web application. 

Another aspect of the invention for a portal server adapted to 
operate a web portal to provide access to a web application; having a 
portlet application operating on the portal server, for managing a 
collection of associated portlets; wherein the portlet application 
includes: means to initiate portlets on requests .of a user to access the 
web application; means to manage a portlet application sBsslon object for 
the portlets; and, a portlet application session object data store 
controlled by the portlet application session object for saving parameters 
from user requests for SLSSociating the portlets with the with the portlet 
application session object, the apparatus incliiding: a portlet application 
communication client (httpCllent) linked to the portlet application data 
store for communicating between the associated portlets and the web 
application to convey user requests received from the ^associated portlets 
to the web application; the portlet application communication client 
having a user session information store (mapping table) for storing user 
session information including selected information from the set of the 
following user session information: user id, user credentials, language 
preferences, session timeout information, session id, etc. for mapping the 
user session information to a corresponding session of the web 
application. 
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^ ^ The session timeout information preferably includes session timeout 
information of the portal serv&r and the web application, 

Another aspect of the invention provides portlet application^ for 
managing a collection of associated portlets in a portal, for operating on 
a server providing access to a web application by a user; the associated 
portlets having portlet recpiest parameter maps storing data and 
instructions from user requests to the portlets; a portlet application 
session object for the user for the associated portlets; a portlet 
application session data store controlled by the portlet application 
session object; a portlet application communication client (httpClient) 
linked to the portlet application data store for communicating between the 
associated portlets and the web application to convey user requests 
received from the associated portlets to the web application; the 
communication client having a request buffer for storing requests from 
portlet request parameter maps of the associated portlets to e n able the. . 
communication client to provide data and instructions for the web 
application. 

Another aspect of the invention provides a portlet application 
coirarajnication client (httpClient) linked to the portlet application data 
store for communicating between the cLSsociated portlets and the web 
application to convey user requests received from the associated portlets 
to the web application; the portlet application communication client 
having a user session information store (mapping table) for storing user 
session information including selected information from the set of the 
following user session information: user id, user credentials, language 
preferences, session timeout information, session id, etc. for mapping the 
user session information to a corresponding session of the web 
application; the session timeout information including session timeout 
information of the portal server and the we application. 

Preferably the above includes synchronization means for the portlet 
application communication client for matching session timeouts between 
portal server and the web application by re-authenticating the user if the 
web application times out before the portal server. 

Another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
portlets in a web portal accessible by a user, the portal server providing 
messaging means for allowing the associated portlets to message each 
other, including: portlet application means for managing the multiple 
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associated portlets; each associated portlet having a portlet descriptor 
describing context names; the eissociated portlets including collaboration 
groups of portlets having corresponding context names defining context 
values; each the group of portlets including a master portlet and at" least 
one slave portlet; wherein each the group of portlets share context names 
in common; means in the portal server for broadcasting coiraounicating 
changes in context values of a master portlet to slave portlets of the 
master portlet; means in the portal server for changing context values of 
the slave portlets to match context values of the master portlet as 
broadcast . 

Another aspect of the invention provides a portlet application 

capable of operating on a portal server for hosting multiple associated . 

portlets in a web portal accessible by a user, the portal searver having 

portlet refresh capability , including: portlet application means for . 

managing the multiple associated portlets; each aussociated pdrtlet liaving 

« 

a portlet descriptor; each portlet descriptor including refresh priority 
description for the portlet; the associated portlets including 
collaboration groups of portlets; each the group of portlets ' including a 
master portlet and at least one slave portlet; means in the portlet 
application means for refreshing the portlets in order of their refresh 
priorities . 

Still another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting imiltiple associated 
portlets in a web portal accessible l>y a user, the portal server having 
portlet refresh capability, including: the associated portlets including 
collaboration groups of portlets; portlet application means for managing 
the multiple associated portlets; each associated portlet having a portlet 
descriptor; each portlet descriptor including a refresh priority 
description for the portlet, and a refresh description priority for the 
group of portlets of which the portlet is a member; each the group of 
portlets including a master portlet and at least one slave portlet; means 
in the portlet application means for refreshing the portlets in order of 
their priorities; means in the portlet application means for refreshing 
the collaborative groups of portlets in order o'f their group refresh 
priorities , 

Hie master portlets have higher priorities than slave portlets. 
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Preferably the portlet application refreshes the groups first in 
group priority order and then refreshes within each group in priority 
order. 

Another aspect of the invention provides apparatus for displaying to 
a user a web page session for a web application, the web page session 
displaying a plurality of associated collaborative portlets, sharing 
information with each other, accessible by the user including: a portal 
server for operating a weOa portal to provide access to the web 
application; a portlet application, for managing a collection of 
associated portlets, for operating on the portaJL server; access means to 
access a amies database; the rules including rules controlling display of 
sets of portlets, pages, page groups to users; selection means to select 
a set of portlets, pages, and page groups to be displayed to a user based 
on information provided by the user { inf oannation properties) . 

In another variation of the. invention the selection means includes a 
pluggable rules engine, a amies database, and a portlet application 
aggregation engine which applies rules to select and display selected 
portlets, pages, and page groups to a user. 

Another aspect of the invention provides apparatus for displaying to 
a user a web page session - for a web application, the web page session 
displaying a pliirality of associated collaborative portlets, sharing 
information with each other, accessible by the user including: a portal . 
searver for operating a web portal to provide access to the web 
application; a poartlet application, for managing a collection of 
associated portlets, for operating on the portal server; roles access 
means to access a roles database; the roles database containing amies 
controlling display of sets of portlets, pages, page groups to users ba^ed 
on user roles; role selection means to select a set of portlets, pages, 
and page groups to be displayed to a user based on an identified role of 
the user. 

Other aspects of the invention provide an article including: a 
computer readable signal bearding medium; con^uter program code means 
recorded on the medium adapted to perf oann the methods of the embodiments 
of the invention described above. 

Other aspects of the invention provide an article including: a 
computer readable sigaial bearing medium; cozrputer program code means 
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recorded on the medium adapted to inclement tlie apparatus of any of the 
embodiments of the invention described above. 

The medium may be selected from the group consisting of magnetic, 
optical, biological/ and atomic data storage media as appropriate. 

The medium may be a modulated ceorrier signal. 

The signal may be a transmission over a network. 

Brief Description of the Drawings 

Embodiments of the present invention will be described by way of 
example, referring to the accompanying drawings in which: 
Figure 1 depicts a Dynamic Context Chaining Model; 
Figure 2 depicts a Web Application Integration With Portal; 
Figure 3 degpicts an Integration Structural Diagram; 
Figure 4 depicts an Integration Flow Diagreun; 

Figure 5 depicts a Structure Diagram for Portal integration with Web 
Application; 

Figure 6 depicts a Flow Chart for Integration; 

Figure 7 depicts an Example Of Dynamic Context Groups for Portlets; 

Figure 8 depicts a Portlet Application Initialization For Dynamic 
Context As Specified In the definition instance; 

Figure 9 depicts a Dynaioic. Context Portlet Group Run Time Flow; 

Figure 10 depicts a ^ole Based Dynamic Aggregation Component 
Structure Hap; 

Figure 11 depicts a Rule Based Dynamic Aggregation Component Flow 

Nap; 

Figure 12 depicts a Role Based Dynamic Aggregation Flow Chart; 
Figure 13 depicts the handling of portlets requests to web 
applications ; 

Figure 14 depicts a sync model diagram; 

Figure 15 depicts a flow chart for a sequence aware portal 
aggregation engine; 

Figure 16 depicts the defining of a dynamic group called *MaleTeen' 
and assigning users to the group; 

Figure 17 depicts the assigning a rules database content group 
selection action to a dynamic user group; and. 

Figure 18 d^icts the creation of a new action called 
'"maleTeenAction" . 
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Detailed Peaorlpfclon of Preferraa Eiabo *q'gtnft«*- q of tAe t^r^i^TxfA^atp. 

IfhlB section describes preferred embodiments of the invention. 

Portal aad A^lleatloas Integration Enablement 

Figure 2 illustrates a preferred embodiment of tlie invention 
illustrating its use witli a web portal server. 

A.1.1 Portlet Application littp client 

The portlet (that makes http requests to the back end web 
application) uses the Portlet Application Http client 209 used to open an 
Http connection to a backend web application that runs on a backend 
application server 210, The backend web application requires a Portlet 
Application Http client 209 to provide session support over multiple 
requests and responses / cookie handling and Single Sign on <SSO) logic. 
All the pprtlets in the same portlet application use the same portlet 
application Http client object 209 to connect to one or more backend* web 
applications. There is one Portlet Application http client 209 per portlet 
application 204. 

Portlet Application Session 

The Portlet Application Session object 208 is a unified data store 
object that can be shared by all port lets in a given portlet application. 
This object exists per user and per portlet application. The Portlet 
Application Session object 208 provides infrasta:uct\ire so that multiple 
portlets in a given portlet application will have independent user 
sessions (called portlet sessions 204 205,206) but share the same Portlet 
Application Session, and communicate with the web application on the 
backend application server 210 with a single web application session. 

Portlet application session context 

Portlet Application Session Context provides information that is per 
user and per portlet education. This means that all portlets within the 
same portlet application (204, 203) can now have a way to share common 
information among them. 
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A*X.4 Session Relay Stechanism 320 

The Session relay mechanism enables the passing of infoxination from 
the original http session held by the portal server to the back end http 
session created by the portlet application's http client. This mechanism 
uses the following inf rastructiire : 

Cookie Table 305 & Cookie X^ookup Key 

Cookie table 305, (a user session information table) is the main 
entity for mapping the portal server cookies to the backend web 
application session cookies. The mapping relationship between the cookie, 
of the http requests to the portal server and the cookie of the portlet 
application http client to one given web application is one to one. 
However, A given portlet application http client can make http requests to 
different web applications with each web application maintaining 
independent sessions. With that regard, the mapping between the portal 
server session cookie and that o{ the backend web applications can be one 
to many (due to multiple backend web application servers) . 

Figure 13 depicts this mapping, in which a nvmiber of items are 
illustrated: 

RQl: cookie from the http request of a user agent (browser) to the 
portal server 

RQA: cookie from the http request of the portlet http application 
client to the web application A 

RQB: cookie from the http request of the portlet http application 
client to the web application B 

The Portlet Application Http client 209 uses this table to look up 
the matching cooJcie to the backend web application running on the backend 
web application server 210. 

The existence of this cookie mapping table 305 enables the automatic 
eaqpiration of a backend web application session when the portal server 
session expires. 

Cookie Xiookop Key 

The portlet application http client 209 is created per portlet 
application. The cookie lookup key is stored in the portal application 
session object which is accessible to all the portlets within the same 
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portlet application.. This cookie loolcup key is responsible for matcliing 
the http session of the portal server with the http session of the back 
end application. 

The use of the cookie lookup key allows all portlets in a given 
portlet application who share the same Http Client key to retrieve and 
forward the correct set of backend web application Inf omiation for the 
currently logged in user such that all the portlets in the same portlet 
application work In synchronization to update the backend web application 
being used. The effect is that the end user sees a unified view of the 
backend web application through multiple portlets. 



Portlet Request S^araneber Map 

The Portlet Request Parameter Map 308 is in a memory object stored 
in the shared application - session data store which is created per portlet, 
per portal server session. It is used to store all request parameters from 
an incoming user request to a particular portlet, 

A* 2. Dynamic Content: Synchronization o£ Portlets 
A.2.1 Dynamic context Definition templau 

Figure 5 illustrates portal integration with a backend web 
application. Reference to Figure 5 will be useful for the following j 

The Dynamic context Definition template 503 defines the following- 
for each Dynamic Context Group: 

the context and its type (in our previous example, it is th.e 
Account ID) 

the master portlet who can change the value of the context 
defined 

the slave portlet (s) who get notified when the defined context 
is changed 

the slave portlet (s) registered response (or action) upon 
notification of the context change 

optionally defines the refresh sequence of the slave portlets 
(master always get refreshed first within a given group) 

One Dynamic Context Definition Template 503 can contain one or many 
Dynamic Context Group (s) . But each Dynamic Context Group can only have 
one master portlet 
one defined context 
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one or more than one slave portlets 

Notes : a given portlet can participate in more than one Dynamic Context 
Groups with different roles in each group. 

5 

A* 2 .2 Dynaxolo Co&teaet Povtle^s Grouping Generation Tool 

This tool 501 reads in the Dynamic Context Definition Template 503 
and generates Dynamic Context Master Portlet and Slave Portlets for all 
10 ' Qynamic Context ^oups according to the definition specified lay updating 

the portlet deployment descriptors 502 correspondingly. 

A.2«3 xtynamLG Cocatext Group 

15 A dynamic context group is a subset of portlets that share the same 

context and are grouped under one dynamic context group. A given portlet 
can belong to more than one dynamic context group. 

The Dynamic context group definition document instance 504 is used 
20 to define the dynamic context of a particular dynamic context group) . 

Dynamic Context Master portlet 

Dynamic Context Master Portlet is responsible for 
25 - detecting the context state change 

notifying all slave portlets on the context state change 

Dynamic Context Slave portlet (s^ 

30 Dynamic Context Slave portlets do the following: 

pulling for context change as notified by the master portlet 
performs the registered action directed towards the • 
corresponding back end application upon notification of 
context change 
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Dynamic Context ^dels 



40 



There are two types of Dynamic Context models that can be used for 
associating portlets with each other: 
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Tlie Syno aodeX 

In the Sync model, depicted in Figure 14, the master portlet 101 
informs the slaves 1701-1703 about the state change of the context of the 
Dynaitiic context master portlet. All slaves will perform actions based on a 
previously defined response to sync up with the master's context state 
change. 

£>ync model diagram 

£k.2«5 The Chaining model 

In the chaining model, indicated' in Figure 1, the change of state in 
Master A 101 results in the response action of Slave A 102, Slave A is 
also the Master portlet B, which leads to the change of state in context 
B, resulting in the context chsuage response of Slave B 103, slave B is . 
also the master portlet of dynamic context group C, resulting in the 
action response of slave c . 

Portilet Transaction isanager: 

A Sequence Aware Portal Aggregation Engine Extension Referring to 
Figure 15, the portlet transaction manager 1802 is the component 
responsible for managing the jruntime refresh secjuencing of the portlets 
including the creation of portlet requests, responses, and sessions. 

1. The first portlet to be refreshed for any portlet application is 
defined as that portlet which is refreshed first among all the portlets 
for a given user. There is no. existing mechanism to define the refreshing 
sequence of portlets within a given page. 

Thus, we need some logic which can identify the master portlet 
dynamically at runtime. In the present invention we use a siir^le 
scratchboard where each portlet makes a mark every time it is refreshed, 
the first time a portlet makes a mark on this scratchboard it knows that 
it is the first or master portlet. The next portlet that makes a mark on 
this list can already see that other portlet has made a mark on it and 
knows that it is not the master portlet, etc. The next time the portal 
page is refreshed, the first portlet that makes a double mark on this list 
becomes the master portlet. The master portlet then, reinitializes this 
list by removing the marks of all the other portlets and also one of its 
do\ible marks for the next request. This algorithm allows us to detect the 
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master portlet dynamically every time a request comes in from the 
portlets' portal server. 

After the first portlet is refreshed the transaction manager takes 
over to refresh the other portlete in the sequence as predefined in the 
master and slave portlet mapping of the dynamic context group. 

2. Seouence sorters The sequence sorter modvile 1804 is M&ed to sort the 
portlets in their refresh sequence order. It used the portlet deployment 
descriptor to identify the refresh order of each portlet and then sorts 
them out for the request dispatching engine. 

3« Se^oence Aware Request Dispatchixig S&giae BxtenBlons This engine 
1805 is used to dispatch requests to the portlets and over-rides the 
portal aggregation engine. Its job is to construct the appropriate portlet 
reqpiest and response objects, as well as the portlet session for all the 
portlets in the commerce portal application. It is then used by the 
transaction manager to actually refresh the portlets. 

4. TransaetiosL Slanager Cachizig tmit s The transaction manager caching 
Unit 1806 is used by the transaction manager 1802 to cache the responses 
produced by the portlets as they eure refreshed by the request dispatching 
engine. This is necessary as when the portal aggregation engine now 
requests for a portlet refresh, these cached responses are sent back to it 
by the transaction manager. This avoids the problem of double refresh per 
incoming portal request. 

A. 3* Bnle Based and Role Based Aggregation 

Figure 11 illustrates a rule based dynamic aggregation component 
structure map of a preferred embodiment of this invention. A description 
of the components of the illustrated einbodiment and their operation 
follow: 

Porbal Resource Translation Module 

The portal resoiirce translation module 1015 is responsible for 
translating the set of Portal resources including: portlets, pages and 
page groups into a form that can be parsed and processed by the external 
rules engine 1022. 
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Rules Database 

The rules database 1001 liolds business manager defined rules for the 
portal aggregation engine 1006. 

user Besooree Translation Module 

The user resource translation module 1013 is responsible for 
translating user resoiirces and the various user properties into a form 
that can be peirsed and worked upon by the external rules engine. 

Pluggable Rules Engine 

The rules engine 1022 is an external, pluggable rules engine (in 
this embodiment of the invention) , such as the websphere personalization 
engine, that is used for dynamic rule pajrsing and execution. The engine's 
execution produces the set of portal resources that the user should see 
based on the business rules defined by the business user and the user 
properties of the current user. 

Portal Roles Based Personalization Sagiae 

The Portal roles based personalization engine 1008 is a roles based 
resource selection module that is used for extracting the list of portal 
resources a user is allowed to access and the list of portal resources the 
user is not allowed to access based on the user's organization membership. 

The roles based engine 1008 first looks at the user's organization 
by accessing the roles database 1007. once the user's organization has 
been determined, his role is assumed to BE the same as the role of that 
organization. After this the roles based personalization engine 1008 
extracts the list of resources that have been defined as accessible and 
inaccessible for this organization by the business user. Once this list 
has been determined IT is forwarded by this module to the portal 
aggregation engine's aggregated resooirce translation subsystem for further 
processing. 

Roles DB 

The Roles DB 1007 holds the organization data for the portal server. 
It holds information about organization membership for various users and 
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also the list of portal resources that mectibera of an organization can and 
can not access based on their roles. 

Portal Asrgrefiratloa Sagina Aggregated Resource ifraaslatloa Subsysteem 

This module 1004 is responsible for creating the master list of 
portal resources that the current user is allowed to see (this includes 
portlets, pages, and page groups) based on the output of the rules and 
roles based personalization engines. This module is also an adapter for 
the actual portal aggregation engine. Its job is to not only create this 
master list but also to translate it into a form that can then be accessed 
by the actual portal aggregation engine for creating the final web site 
for the end user. 

Part B« Qperafcional Desorlption 

B.l Portal and Web Application Integration Enabling Description 
B.1.1 Overall Integration Structure & Plow Diagrams 

Figures 2, 3, and 4, depict respectively- web application 
integration with a portal; an integration structural diagram; and an 
integration flow diagram. 

B.l .2 Det:aiXed Deserlptilon 

Referring to Figure 2, when a backend web application is integrated 
with portal server, the backend web application 221 receives re<3[uests from 
the portal server 201 via port lets. The backend web application 221 sends 
responses back to the portlet making the req^iest. 

The response from the web application 221 is rendered via portlets 
of the portal server 201 to a user accessing the portlet. 

with the implementation of the Portal Application HTTP client 209 
multiple re<iuests and responses to the backend web application are 
perceived fay the back end web application as cohesive sessions. The Portal 
Application Http client 209 is us.ed to open Http communication connections 
to the backend web application 221. The backend web application requires 
the Portal Application Http client 209 to provide session support, cookie 
handling and Single Sign On (SSO) capabilities, With the Portal 
Application HTTP client 209 in place, the portlets can effectively 
communicate with web application. All the portlets in a portlet 
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application (such as portlet application 205) need to have access to one 
portlet application session object 211 of the back-end application 221, 
that means that Portal Application Http client 209 must be shared by all 
the portlets within the aazne portal application. 

To make such sharing possible we have determined that a unified 

session object that can be shared by all portlets in a given portal 

application is needed. To provide such an object the invention herein 

provides a Portlet Application Session object 208. The Portlet Application 

session object 208 is an object that is created by the commerce portlet 

application. The portlet application session object 208 is accessible by 

all portlets in a given portlet application (such as portlets 204, 205, 

206 in portlet application 1, 207) . Without the portlet application 

session object, 208, multiple portlets in a given portal application will 

all have independent user sessions and will not be able to share session 

related information. 
* 

The Portlet Application Http client 209 is stored in the Portlet 
Application Session 208, making it possible to share it among portlets in 
the same portlet application- Without this portlet application session 
object it would not be possible for the portlets to communicate with a 
single web application session on the backend. 

All the data tliat is stored in the Portal Application Session object 
208 represents Portal Application Session context and exists per user per 
portal application. 

Since the Portlet Application http client 209 holds all session 
information for the back-end web application 221, it is \ised as a base for 
the Session Relay mechanism 320 depicted in fig. 3. 

Session relaying allows session information to be relayed that is 
specific to the whole portal server 201 (such as language information, 
user agent dLnforxnation, etc) to the session information of the back-end 
web application 221. That means that the back-end web application 221 is 
able to deliver the data representation that conforms to all the 
requirements contaoned in the original request s^t to the portal seorver 
by a user. 

For exaicple, if the user accesses the portal using a WAP (wireless 
application protocol) enabled mobile device, with default language locale 
set to 'French" then The original http request to the portal server 201 
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will have ITS language parameter set to ^French'" and user-agent field of 
the HTTP header set to ^WAP" . The Session Relay mechanism 320 relays this 
information to the web-application 221 and the web application returns a 
response in French that is suitable for display on the user's mobile 
5 device in French, If the Session Relaying were absent the web-application 

would return the information in the default- language (for exaitrple English) 
suited for the default device (for exanrple an Internet Browser) . In that 
case the user would not be able to see the retrieved data as it would be 
incompatible with the user's mobile device. 

10 

Reference will be made to elements in the structxiral diagram Figure 
3 while process steps of Figure 4 will be indicated by enimierate steps. 

Step 401, the user interacts with port lets on a web portal,, for 
15 instance by using a computer mouse to click on a link or object displayed 

in a portlet on the user's web browser . Each port let has its own portlet 
session 310 (portlet session is a piece of prior art) . As paurt of the 
user interaction, a remote request 306 is being made to be backend web 
application 307. 

20 

2. Step 403, in order to pass all the parameters in the portlet session 
correctly to the backend web application each portlet request's parameter 
list is saved in the Portlet Request Parameter Map (#8) 308. These 
paxameters are passed to the remote back end request. 

25 

3. Step 404, the commerce portlet uses a http client key 301 to 
deteimine if there is already an existing Portlet Application Session 
Object 208 and Portlet Application Http Client 303 by accessing portlet 
application data store #4, 302. step 405, If one is not found, a new one 

30' will be created for all the portlets within the same portlet application. 

(Step 407, If one is found, the existing one will be used instead.) 

4. Step 406, each user credential from the original portlet session is 
saved in the cookie table 305. 

35 

5. Step 408, the user credentials from the cookie table 305 and the 
parameters previously saved in the portlet request parameter map 308 are 
used to construct a new http request to the backend web application. 



40 



6. Step 409, the call to ronote web application is made 307. 
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7. Step 410, the remote web application 307 returns a response to the 

call for the port let to display. 

B*2 X^ynamia Context Slyxiohroalsaticn o£ Portlets 

B»2*l BeveloipQRieni: Tinte Desoriptdon 

Referring to Figure 5 which depicts a structural diagram of portal 
integration with a backend web application, it may be seen that a portal 
developer can make use of the Dynamic Context Portlet Grouping Tool 501 to 
create each new Dynamic Group Definition Instance 504 . This instance is a 
grouping of associate portlets and defines which portlets are slaves and 
which portlet is the master of those slaves. The required elements of the 
Dynazoic Group Definition MsCB specified in the Dynamic Context Group 
Definition Template 503. 

User uses the same tool 501 to update an existing Dynamic Context 
Group Definition. 

After the user has provided the latest dynamic context group 
definition^ the Dynamic Context Portlet Grouping Tool 501 updates the 
appropriate portlet application deployment descriptors 502 to reflect the 
relationships defined in the group. 

Referring to Figure 6, a flow chart representing portal integration 
the steps of the above process may be more clearly visualizedt 

When a user wants to create ($08} or update (609) a dynamic context 
group, the user can employ the grouping tool 501 (Fig. 5) . 

601, the dynamic context grouping tool prompts for user input based 
on what is specified in the dynamic context group definition template 503, 
or in the case of updating the dynamic context grouping tool reads in an 
existing dynamic context group instance, validating it with the definition 
teztiplate 503. 

603, the user specifies the required information to define or update 
a dynamic context group. 

605, the dynamic context group instance 504 is generated. 

606, the deployment descriptor of all related portlets are updated. 
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Dynamic C ontext Grouping 

Figure 7 illustrates dynamic context for portlets. Dynamic group 
701 is comprised of master portlet 704, slave portlet 705, and slave 
portlet 707, 

Group 703 is con^prised of master portlet 705, slave portlet 706, and 
slave portlet 707. 

Dynamic group 702 is comprised of master portlet 704 and slave 
portlet 708. 

If the 'data that is represented by portlets in a l?ortlet Application 
is synchronized at the back-end application level, then the portlets 
deliver a coordinated view of the data just by retrieving that data from 
the web application. However, not all portlet interactions result in the 
changes at the backend web application. Dynamic context serves as the 
synchronization *at the glass'. It is most effective when a change in 
context requires a different cjuery. For example, selecting a different 
account from the acco\ant list requires displaying of invoice information 
being refreshed with the account selected. 

In prior art systems Portlets were normally independent of each 
another. This invention provides method and apparatus to map the relations 
of portlets with each other and articulate their dependency on each other 
at portlet application deployment and configuration time. The portlets 
themselves do not need to be changed. 

•The dependency relationships among portlets can be defined in a 
Dynamic Context Relationship Template 503 in which the master and slave 
relationships are defined. 

The Dynamic Context Relationship Template 503 is preferably encoded 
as an XML data representation that. defines the following: 

the subset of portlets that constitute a dynamic context group 

the tnafiter -Qortlet of a dynaiaic context group 

the slave (s^ portlet of this dynamic context group 

the slave action that the slave (s) have to perform upon 

context state changes 

the context that all constituents of this dynamic context 
group sheire 
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An example o£ a pynamic Context Group definition instance follows: 

<DynataicContext6roup> 

<DynainicContext6roupNatae>0rderRelatedPortlet6roup 
5 </Dyx]amiGContextGroupName> 

<PynaniicContextMasterPortlet> 

Orderltems 
</DynaiaicContextMasterPortlet> 
<DynamicConte}ct>itexilNaine 
10 </DynainicContext> 

<Dynaini cCon t ext S 1 avePort 1 et > 

<DynamicContextSlavePortletName>UPSTracking 
< /DynamicContext SlavePortletNaine> 
<SlavePortletAction> 
15 , http : / /inventorvserver . com/inStock/ 

< / SlavePort letAct ion> 
</I>ynainicContextSlavePortlet> 
</I)ynaiaicContextGroup> 

20 <DynamicContextGroup> 

<IDynamicContextGroupName>StockInventoryPortletGroup 
</pynaini cCont extGroupName> 
<:DynainicContextMasterPortlet> 
InStocklnventory 
25 </DynamicContextMasterPortlet> 

<DynainicContext>itemSKUnuinber 
</I>ynaiaicContext> 
<DynamicContextSlavePortlet> 

<DynamicContextSlavePortletName>OrderedItQns 
3 0 </DynamicContextSlavePortletName> 

<SlavePort letAct i on> 

http : / /scyserver . com/lastOrdered/ 
</ SlavePort letAct ion> 
</Dynai3iicContextSlavePortlet> 
35 . </DynainicContextGroup> 

The dynamic context group Definition Instances note: one dynamic 
context group definition is one instance. However, multiple dynamic 
context group definitions can be consolidated into one file to define 
40 multiple instances above defines two portlet sets in a portlet application 

consisting of 3 portlets. 
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In the first dynamic context group, the dynamic context shared 
between the portlets is iteznName, the portlet named Orderedltems serves as 
Dynamic context Master portlet and portlets UPSTracking and 
InStocklnventory serve as the Dynaxaic context Slave portlets. 

In the second dynamic context group, the dynamic context shared 
between the portlets is itemSkuNumber^ the portlet named InStocklnventory 
serves as Dynamic context Master portlet and portlet Orderedltems and 
serves as the Dynamic context Slave portlets. 

Each Dynamic context Master portlet observes a user HTTP request and 
looks for the dynamic context. If the dynamic context is found in the 
request, the dynamic context portlet sends a dynamic context (which is the 
name and value pair parameter in the http request) to the Slave portlets. 

For example if Orderedltems portlet receives an HTTP request with 
attribute iteroName set to 'PentiumlV" it sends the dynamic context to the 
portlets UPSTracking and InStocklnventory notifying them that context 
itemName with value *PentiumIV' was now set in the dynamic context. 

Each Dynamic context Slave portlet listens to the master's 
notification to all slave portlets of the same dynamic context group- Upon 
receiving the master's notification, the corresponding slave action is 
invoked by adding the dynamic context to the action URIj as defined in the 
dynamic context group definition instance under attribute 
* SlavePortletAc tion ' . 

For example if inStocklnventory portlet receives the dynamic context 
from Orderltems portlet with dynamic context type ^itenrtisrame* and value 
'PentiumlV* it will retrieve the data from the 

http : // invent orvserver - coin/inStock/it emNaine=PentiuinIV URL. 

Coding for an example of a Dynamic Context Group Definition Template 
follows : 

<xsd: schema 

xmlns : xsd=s "ht tp : / /www . w3 . org/2 0 01 /XMLSchCTia " 
xmlns : c^= 

http : / /www - ibm. com/WebsphereCommerceEnabledPortal/DynamicContex 
tGroupDef initionSchema" > 

<annotation> 
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<docuinentation xml : lang= " en " > 

Schema for Websphere Commerce Enabled Port:al Dynamic Context: 
Group Definition 

Copyright 2002 IBM Corporation 
<docuinentation> 

</annotation> 

< I— Dynamic Context Group Instance — > 
<xsd : element name= 'DynaxnicContextGroup " 

type="DynamicContextGroupDef initionTemplate" , 

minOccur s~ " 1 ' / > 

< I— Dynamic Context Group Definition Ten^late Schema _ 
<xsd: complex?rype name="DynamicContextGroupDef initionTemplate" > 
<xsd : seciuence> 

<xsd : el ement naxne= " DynamicCont extGroupH^ooe " 
types "xsd: string" /> 

<xsd: element naine~''I)y3iamicContext]MGaBt:erPortlet:'' 
type=*PortletName' /> 

<!- only one dynamic context per dynamic context group -> 

<xsd: element name="DynamicConteiet'' types'ContextPearameter" 
maxOccurs= *1 ' /> 

<xsd: element name=*'PynamicContextSlavePortlet:" 
type* " SlavePor tlet * 

minOccurs= " 1 " /> 

</xsd: sequence> 
</xsd: coiiiplexType> 

<xsd2complex!rype name= " SlavePortlet " > 

<xsd : se<xuence> 
<xsd: element name="DynamicContext SlavePortlet;" 
type= " PortletName" /> 

<xsd: element name=* SlavePortlet Action" type=''xsd:string''/> 
<xsd : element names " SXavePort letIle£reshFriority ' 
type= »xsd : decimal " , 

ininOccurs=»' 0 * /> 

<i- master's context is in the slave action url if slave param 
map is absent — > 

<xsd : element name- ' SlaveParairtMapToContext * 
type«*ContextParjEaiieter» 

minOccurss" 0 • /> 
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</xsd: sequence> 
</xsd ; ccanpi ex5*ype> 

<xsd:siinpleType name="PortletName»> 
<xsd : 8tring> 

</xsd : siinpIeType> 

<l— liame of the paxameter in master's request url — > 

<xsd : sin^leOVPe name= " ContextParameter " > 
<xsd : s tr ing> 

</xsd: simpleType> 

< /xsd : schema> 

Ron Vine 

This section will best understood by referring to Figure 8: Portlet 
implication Initialization For Dynamic Context As Specified In The 
Definition Instance; and 

Figure 9: Dynamic Context Portlet Group R\xn Time Plow, 

There are two key component to handle Rttntime aspects of the Dynamic 
Context : 

1) DynamicContextActionliistener (904) (Portlet Action Listener) - it 
listens for the dynaiaic context change in the Master portlet. Master 
portlet in every Dynamic Context Portlet Group has 
DynamicContextActionliistener attached to it. 

2) DynamicContextMessageListener (906) (Portlet Message Iiistener) — 
is the Message Listener listens for the notification from the Master of 
the group where specific Qynamic Context is defined. Every Slave portlet 
in the pynamic Context Portlets Group has a DynamicContextMessageListener 
attached to it. 

Step-by- step description o£ the run-time £lowt 

At portlet initialization time (Pig 8: 801), all master portlets 
will add the defined dynamic context based on the portlet descriptor (802, 
805) to the master portlet's action listener (806). For all slave 
portlets; the dynamic context type; the action url; the parameter mapping 
and the refresh sequence, will be retrieved from the portlet descriptor 
(802, 809) and add to the slave's portlet message listener (810). 
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1) The -user interaction with the Dynamic Context Portlet Group 
Master portlet results in the change of the Dynamic Context (901) . 

2) Master's Portlet DynamicCoritextActionliistener detects the user's 
action (902) . 

3) DynamicContextActionListener sets the name/value pair 
corresponding to the Dynamic Context in the requests object of the Master 
Portlet (904) . 

4) Master Portlet gets the value of the Dynamic Context and notifies 
all the slave portlets within the same dynamic portlet group about it 
(905) . 

5) DynamicContextMessageListener associated with the Slave portlet 
for the given Master receives the notification (the value of the dynamic 
context) (906) . 

6) DynamicContextMessageListener sets the value of the 
DynamicContext in the portlet request object of the slave portlet. (907) • 

7) The Slave portlet gets the value of the dynamic context (1008) . 

8) The Slave Portlet modifies action defined for the given Slave 
Portlet if the mapping between context and some parameter was specified 
(1009) . 

9) If the mapping was not specified, the name/value pair of the 
dynamic context is added to the Slave's Portlet action. 

10) Slave Portlet performs the Action as defined in the dynamic 
context group instance definition (1011, 1012) . 

B.3 Rule Based Role Based Dynamic Aggregation 

A n\3inber of figures will be referred to in this section including: 
Figure 10: Role Based Dynamic Aggregation Component Structure Map; Figxire 
11: Rule Based Dynamic Aggregation Component Structure Map; and, Figure 
12: Rule Based Dynamic Aggregation Flow Chart. 

The role and rules based dynamic aggregation components for the 
portlet server are based around the rules and roles databases and the 
concept of content groups for each role and rule- 

The content groups for the rules are kept in the Rules DB cos^onent 
1001 shown in Figure 10. Similarly the* roles content groups are defined in 
the Roles DB component 1007 shown in Figiire 10. Each content group 
consists of a set of portal server resources that a user who has been 
evaluated to fall under the purview of that particular role or rule should 
have access to. 
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Another major coinponent in this scheme is the Pluggable Rules Engine 
1022* The task of this engine is to read in the translated user properties 
and decide dynamically at runtime the set of users who qualify for 
membership of a certain predefined user groijp based on these user 
properties. Also this engine maps the set of these dynamic user groups to 
the set of content groups that have been defined in the roles and rules 
DB. Preferably the Pluggable Rules Engine has a GUI to manage these tasks. 
The screen shot depicted in Figure 16 illustrates how we use the WebSphere 
Personalization Server Engine to manage these tasks. 

For example. Figure 16 illustrates how we define a dynamic group 
called ''MaleTeen" and assigns all male users of ages between 16-19 to this' 
group . 

As shown in Figure 17, which depicts all users who are dynamically 
evaluated to be male teenagers based on their properties will now have the 
"^maleteenaction" command executed for them which would instruct the 
dynamic rules and roles based portal aggregation engine 1022 to select 
content resource for the stale teen group from the Roles DB 1007. 

At development time it is the task of a business manager to assign a 
set of portal reso\irces such as: pages, portlets etc. to a specific 
content group in the Roles and Rules DB. This is currently done by using 
SQIi scripts that directly load the Rules and Roles DB. 

B«3«l Rule Based Role Based Dynamic Aggregation Ran Time EnaJsllng 
Desariptioa 

At runtime the first command to execute for a portal user is the 
wrapper command for the rules based engine. This command is actually a 
proxy that starts the evaluation of user's properties by the actual 
pluggable rales engine. 

In the next step the rules engine reads in the user's properties 
from his stored profile, by utilizing the user resource translation module 
to translate them into a form that can be understood by it. 

Figuuce 18 illustrates the creation of a new action called 
*MaleTeenAction^ which selects all the portal resources that have been 
defined in the content group called ^maleteengrp'' in the rules DB. 
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Figure 17 illustrates creation of a dynamic aggregation module 
command instructing the aggregation module to select the contents of the 
^maleteengxp" for all the users who fall under the purview of the 
previously created rule for classifying ''H^leTeens'' based on dyziamic user 
properties . 

Figure 17 illustrates how a given business rule (e.g. business rule 
in defining what constitutes a maleteen groyjp) tetkes effect (e.g. 
maleTeenAction) in determining what content to aggregate for a given user, 
with a certain user properties, falls under such classification. 

After reading in the user properties the pluggable amies engine 
evaluates the dynamic group membership of this user based on the rules 
defined for the various dynamic groups as shown in Figure 18. 

Once the set of dynamic groups for this user has been ascertained 
the rules engine selects the appropriate portal content for this user by 
executing the content select ion actions defined for this dynamic group as 
shown in Figure 18. These actions upon execution return the set of portal 
resoxirces from the content groups defined for them in the Rules DB. 

The next execution step is the evalviation of the roles assigned to 
this user by the roles engine. The roles engine uses the organization 
membership (extracted from the user profile properties) to extract the set 
of content resources for this user's role from the Roles DB. These 
resources are then added to the eaready existing list of rules based 
portal resources created in the previous set. 

This list is then forwarded to the dynamic Portal Aggregation Engine 
for execution. The dynamic portal aggregation engine then selects the 
portal resources identified by this list to set up the default portal view 
for this current user. 

Summary 

1. Common Backend Web Application Integration iinplementation 

with the Portlet Application Http Client and Portlet Application 
Session, It is how possible to have a common backend web application 
integration model. This can be used to enable multiple portlets within the 
same portlet application to communicate with the same web application 
backend. 
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This implementation of the invention makes it possible to: 
i. have native port let integration without laianching separate 
browsers, and without requiring xmiltiple proxttpts £or user id and password 
to access the same backend web application; 
5 ii. make multiple requests and receive responses to/from the backend 

application with session management. 

2. Siinple Common system leading to simple tooling 

10 The instant invention, provides an easy and quick method to 

integrate portlet applications with an existing web application operating 
on a backend server; with merely requiring the specification of the url of 
the pertinent backend web application in the deployment descriptor of the 
portlet application. With this, it is now possible to build tooling to 

15 take care of the commonality tasks of the integration, 

3. Portlets Within The Portlet Application Share Common Session and 
Session Data 

20 The io^lementation of a portlet application session object makes it 

possible for portlets of the same portlet application to share common data 
among themselves that are unique within a portlet application, while at 
the same time being different from that of the original http session of 
the portal server. This facilitates the sharing of data unique among the 

25 portlets within the same portlet application. 

4. Portal Session and Back End Session Sharing Common Session Data 

The session relay implementation makes possible the sharing of 
30 common session data between a portal server and its backend web 

application. This enables the backend web application to receive 
information from the portal server, enabling business logic of the web 
application to e^sploit this information passed from the portal server . 

35 For example: if the current portlet state is to display the 

maximized view of the portlet, the backend web application can receive 
this piece of information and take advantage of this by sending back 
detailed business information, in contrast to the normal view of a 
portlet, in which case the backend web application would just send a 

40 summary version of the information. 
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5. Cohesive Back End Web Application Session Distinct From The Portal 
Server with the portlet application session, portlet application session 
object, portlet http client, and the session relay mechanism A back end 
web application can now preserve its own session distinct from that of the 
portal server, but still share the same cookie with that of the portal 
server. The backend web application can now operate independently and 
correctly, perceiving portlet requests from various portlets in a portal 
as one virtual client, enabling a cohesive session with- the backend web 
application. 

6. Single Sign On Across Portal Sezver and Back End Web Application 

The session relay enbodiment provides single sign-on capability such 
that the user, once logged on to a portal server, is not required to 
resubmit user credentials to log on to the pertinent back end web 
application. This is enabled by means of a cookie table with one to one 
mapping between the http session to the portal and the http session from 
the portlet http client to the backend web application. 

7 . Back End Web Application Behavior Synchronized With That of the 
Portal Server 

The session relay exnbodiment enables enabling seamless integration 
by synchronizing the behavior of a backend web application by relaying the 
session information from the portal session to the session of the back end 
web application. 

The following are some examples: 

The language and locale setting in a portal server can now be passed 
to its backend web application so that the backend application can now 
cosnpose a response message based on the locale + language setting of the 
portal server. 

Another example is that session expiry information from the portal 
server can now be passed to the backend web application session so that 
the backend web application session can now be timed out at the same time 
that the portal session times out. The backend web application can now be 
responsive to the portal state and events as relayed from the portal 
server. 
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8. Synchronized Content Within The Same Portal Page 

Pynatnic Context Portlet Grouping allows ^collaboration among portlets 
within the same dynamic context group to achieve business process and 
information integration and synchronization. 

Each, portlet is allowed to participate in multiple Dynamic Context 
Groups. This provides a very open and simple programming model for portal 
administrator to group portlets into dynamic context portlet groups. 

The simple structure of Dynamic Context definition enables simple 
tooling to be built for automatic generation of Dynamic Context Master and 
Slave portlets for each grouping. 

Dynamic Context Definition implementation. Dynamic Context Group, 
master portlet and slave portlet implementation (including the slave 
tasks, slave context map) assist in providing advantages of the invention. 

9. ilbility To Define Refresh Sequence of Portlets ^ 

The transaction manager provides the capability of defining a 
refresh sequence of portlets for the first time. The ability to define 
refresh sequence of portlets enables proper implementation of sequential 
business logic using the portal / portlet architecture. The transaction 
manager; resource sorter; the caching of responses assist in providing 
advantages of the invention. 

10. Rule Based and Role Based Aggregation 

Fine level portal personalization can only be achieved at present by 
dynamic aggregation. This is distinctly different from the prior art 
implementation of regular w^ applications in which there is no f ormaJ. 
concept of portlets, pages or page groups applied in accordance with the 
instant invention. Pine level personalization will become more and more 
important as the portal market takes off and user requirements for fine 
level campaign targeting etc. come in. 

The embodiments of the invention provide a number of advantages 
which are listed below: 

1. The level of personalization that can be achieved by our approach is 
much finer grained than. Portlet administration facilities provided by 
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portal server today. The portlet administration facilities available today 
is by nature manual configuration. Once configured, it is static and does 
not change at run time. The invention here provides a dynamic capabilities 
to render portal resoiirces based on rule. 

2. Since the portal aggregation module is a dynamic entity, tying of 
rules and roles engines directly to it lets us achieve real-time dynamic 
aggregation capabilities without any human intervention, 

3. Personalization of coarse grained portal resources such as pages and 
page groups lets us perform dynamic layout. 

•4. Much more effective campaigns, contracts etc. can be set up. This is 
of significant inqportance to both e-Commerce retail and B2B organizations. 

5. the invention allows a much higher degree of personalization than 
regular content personalizat:ion. For example, we can actually disable 
entire sections of a webpage based on rules. This can't be done by regular 
personalization. Further, dynamic aggregation doesn't apply to the domain 
of regular personalization which is content, not resource related. 



